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Abstract. Embedded systems are everywhere, from home appliances to 
critical systems such as medical devices. They usually have associated 
timing constraints that need to be verified for the implementation. Here, 
we use an untimed bounded model checker to verify timing properties 
of embedded C programs. We propose an approach to specify discrete 
time timing constraints using code annotations. The annotated code is 
then automatically translated to code that manipulates auxiliary timer 
variables and is thus suitable as input to conventional, untimed software 
model checker such as ESBMC. Thus, we can check timing constraints 
in the same way and at the same time as untimed system requirements, 
and even allow for interaction between them. We applied the proposed 
method in a case study, and verified timing constraints of a pulse oxime- 
ter, a noninvasive medical device that measures the oxygen saturation of 
arterial blood. 

1 Introduction 

Model checking is an automatic technique for verifying finite state concurrent 
systems [S] ■ The main problem in model checking is the well-known state space 
explosion; adding real-time aspects to model checking only makes this problem 
worse. Usually, real-time systems are modeled by timed automata, timed Petri 
net, or a kind of labeled state graphs, and verified with specialized timed model 
checking tools, such as TINA [T], HyTech [S], Kronos [16], or UPPAAL [TT] . 
For example, UPPAAL uses timed automata as input and a fragment of the 
TCTL temporal logic (T5J to prove a safety property in an explicit-state model 
checking style. Here, we propose a different approach. In our method, the safety 
property is specified in an explicit-time style [10], using discrete-time timing 
annotations in ANSI-C programs. We assume that timing annotations are given 
externally, either be a WCET analysis of the code, or by a domain expert. We 
then translate such annotated C code automatically to code that manipulates 
auxiliary timer variables. This code is suitable as input for a conventional (i.e., 
untimed) software model checker; since we are working with a discrete-time 
model, timing assertions can simply be interpreted as integer constraints. 



In our implementation, we use ESBMC [3] , a bounded symbolic model checker 
for ANSI-C which is based on satisfiability modulo theories (SMT) techniques, 
while specialized timed model checkers typically adopt an explicit-state style 
(e.g., UPPAAL). Symbolic model checkers can typically explore more states than 
explicit-state model checkers, despite some state-space reduction techniques. 
Moreover, symbolic model checking can easily be combined with powerful sym- 
bolic reasoning methods such as decision procedures and SMT solving. This 
reduces not only the state space but also allows us to handle timing constraints 
symbolically yet precisely. Note that the timing annotations need to be treated 
separately from the other assertions during loop unrolling (which is a crucial 
step in bounded model checking) in order to get correct results. We avoid this 
problem by annotating only function definitions. 

Many safety-critical software systems are written in low-level languages such 
as ANSI-C. However, to the best of our knowledge, there is at present no tool 
that translates C code with timing constraints to either timed automata or timed 
Petri nets. The main aim of this paper is thus to propose a method to check 
timing properties directly in the actual C code using a (conventional) software 
model checker; however, we can check timing properties as well as safety and 
liveness properties (see [5]). The proposed solution should not be considered as 
an alternative to other methods, but rather as complementary. There are at least 
two scenarios in which it can be used: (1) for legacy code that does not have a 
model, or where there are no automated tools to extract a faithful model from 
the code; and (2) when there is no guarantee that the final code is in strict 
accordance with the model. 

We focus on time-critical embedded systems software which, due to pre- 
dictability issues, require guarantees that in all execution paths the timing con- 
straints are met. We illustrate our approach through an industrial case study 
involving a medical device called pulse oximeter. Our experiments show that our 
technique can be used efficiently for verifying embedded real-time systems using 
an existing untimed model checker. 

The main contribution of this work is to check timing properties in the same 
way as for untimed systems. Specifically: we use code annotation to express 
timing properties; we describe our translation from the annotated code to a code 
suitable for model checking; and we report experiments on a medical device. 

The paper is organized as follows. The next section shows the background 
to understand the proposed method. Section 3 describes the proposed method. 
Section 4 analyzes the pulse oximeter case study. Section 5 reviews related work. 
Finally, Section 6 summarizes the paper and explains future work. 

2 Backgroud 

2.1 Model Checking with ESBMC 

ESBMC is a context-bounded model checker for embedded ANSI-C software 
based on SMT solvers, which allows the verification of single- and multi-threaded 



software with shared variables and locks |6I5] , although we have focused in single- 
threaded software here. ESBMC supports full ANSI-C, and can verify programs 
that make use of bit-level, arrays, pointers, structs, unions, memory allocation 
and fixed-point arithmetic. It can efficiently reason about arithmetic under- and 
overflows, pointer safety, memory leaks, array bounds violations, atomicity and 
order violations, local and global deadlocks, data races, and user-specified asser- 
tions. 

In ESBMC, the program to be analyzed is modelled as a state transition 
system M = (S,R,So), which is extracted from the control-flow graph (CFG). 
S represents the set of states, R C S x S represents the set of transitions (i.e., 
pairs of states specifying how the system can move from state to state) and 
so C S represents the set of initial states. A state s £ S consists of the value 
of the program counter pc and the values of all program variables. An initial 
state so assigns the initial program location of the CFG to pc. We identify each 
transition 7 = (sj,Sj+i) £ R between two states Si and Sj+i with a logical 
formula j(si, s,+i) that captures the constraints on the corresponding values of 
the program counter and the program variables. 

Given the transition system M, a safety property 0, a context bound C and 
a bound k, ESBMC builds a reachability tree (RT) that represents the program 
unfolding for C, k and (j>. We then derive a VC ip% for each given interleaving 
(or computation path) tt = {isi, . . . , such that ip^ is satisfiable if and only 
if <j> has a counterexample of depth k that is exhibited by 7r. tp^ is given by the 
following logical formula: 

k i— 1 

V k = /(so) A \/ A A ^) (!) 

i=0 j=0 

Here, I characterizes the set of initial states of M and ^(sj, Sj+i) is the transi- 
tion relation of M between time steps j and j + Hence, I(so)A/\ l j_ Q j{sj, Sj+i) 
represents executions of M of length i and ijiT can be satisfied if and only if for 
some i < k there exists a reachable state along it at time step i in which <j> is 
violated, ipfc is a quantifier-free formula in a dccidable subset of first-order logic, 
which is checked for satisfiability by an SMT solver. If is satisfiable, then </> 
is violated along it and the SMT solver provides a satisfying assignment, from 
which we can extract the values of the program variables to construct a counter- 
example. A counter-example for a property is a sequence of states so, si, . . . , Sfc 
with so G So, Sk £ S, and 7(si,s;+i) for < i < k. If ip^. is unsatisfiable, we 
can conclude that no error state is reachable in k steps or less along it. Finally, 
we can define %pk = anc ^ use this to check all paths. 

2.2 Model Checking Real-Time Systems 

Model checking is a verification technique that applies to systems that can be 
modeled by a mathematical formalism (finite automata and Petri nets are exam- 
ples). In practice, the size of the systems is really the main obstacle to overcome. 



Therefore, model checker users usually simplify the model under analysis. Model 
checking consists in three steps. (1) Mathematical representation (modeling). 
Usually such models represents states and transitions, and may be composed 
by and synchonized by several components. (2) Representation of a property by 
a logical formula. Once the model is built, we formally state the properties to 
be checked, usually in a temporal logic. (3) Model checking algorithm. Given a 
model A and a property </>, a model checking algorithm answers the question: 
"does the model A satisfy the property cj)T' 

There are several tools that model check real-time systems. 

TSMV [T2] is a symbolic model checker that verifies TCTL formulas on 
Timed Kripke Structures (TKS), i.e. finite state graphs where transitions carry 
a duration. The main feature of TKS's is that the durations of transitions are 
atomic, that is, when moving from state s to state s' in a step that lasts 10 
time units, there is no intermediary configuration between s at time t and s' at 
time t + 10. The key motivation for this semantics is that it leads to simple and 
efficient model checking algorithms. 

UPPAAL [11] allows one to analyze networks of timed automata with bi- 
nary synchronization. It contains three main parts: (i) a graphical editor where 
timed process are described; (ii) a simulator where it is possible to choose a 
sequence of transitions, and to see the behavior of the system; and (iii) a verifier 
of reachability properties. The main drawbacks of UPPAAL are: (1) the binary 
synchronization is a bit restrictive and requires one to use ad hoc mechanisms to 
describe other kinds of synchronizations (e.g., broadcast); (2) the specification 
language considers only reachability properties and not a full temporal logic. 
This entails that it is necessary to include a observer automata to express com- 
plex properties. 

KRONOS [16] is a model checker that can decide whether some property, 
expressed by a TCTL formula, holds for a timed automaton (also called timed 
graph), given in textual form. It allows one to verify liveness properties, and 
is not restricted to reachability properties. Even though KRONOS contains no 
graphical nor simulation modes, it is a true timed model checker. However, under 
its current form, it is mostly intended for advanced users with a good knowledge 
of formal methods. 

HYTECH [S] receives a set of linear hybrid automata, and synchronizes them 
by some common transitions. From the automata in a textual form, HYTECH 
can compute subsets of the global state space. HYTECH also handles parametric 
analysis, that is, when a system (or a property) contains parameters, the analysis 
can provide the parameter values for which the property holds. The drawbacks 
of HYTECH is that it includes no simulation mode; model checking does not 
apply to a temporal logic: the user has to build himself the subset of states to 
be computed by combinations of basic constraints. 

TINA [Tj is a toolbox for the edition and analysis of Petri Nets and Time 
Petri Nets. The Tina toolbox includes several tools such as: (i) an editor for 
graphically or textually described Time Petri nets; (ii) construction of reacha- 
bility graphs where it may build coverability graphs, persistent sets, state class 
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Fig. 1. Overview of the Proposed Method 



graphs, and (iii) a state/event LTL model checker that checks reachability prop- 
erties. However, it is difficult to check real-time quantitative properties. 

3 Proposed Method 

This section describes the method proposed to verify timing properties on single- 
threaded C code using a bounded model model-checker. Figure Q] gives an overview 
of the approach. It is divided into four phases. The first step is to add timing 
constraints to the source code. Such annotations come from either a discrete tim- 
ing model, a timing analyzer tool, or a domain expert. As usual, the annotations 
are just comments that are processed by a specific tool. The second step is the 
automatic translation from the annotated source code to new code that can be 
verified by the untimed model-checker. Basically, this translation consists in (i) 
adding declarations of the timer variables; (ii) gathering the annotated timing 
constraints information and including assignment statments for the new added 
variables; (iii) adding (user-defined) assert statements at specific points of the 
program code. The third step is to check the translated code with the ESBMC 
model checker. Finally, the last phase, evaluates ESBMC's results. As shown, 
the way to check timing properties is by using assertion. 

3.1 Timed Programming Model 

The proposed method aims to pragmatically assist developers in the specifica- 
tion and analysis of timing constraints in C code. What we propose is (i) to 
associate with each function fa a worst-case duration di > 0; (ii) to define ex- 
plicit timer variables (or clocks) (7~), for expressing timing constraints; (iii) to 
introduce timing assertions on timer variables to check timing properties; and 



(iv) to introduce timer variable reset to restart the timer counting. Therefore, 
when the program is executed, the timer variables are incremented by the re- 
spective duration di of the called function /j, and assertions are used to ensure 
that computations are within timing constraints. 

Formally, let consider that the semantics of a sequential program V is repre- 
sented by the 5-tuple (<S, Sq, V, J 7 , — where: 

— S is a finite set of states of V; 

— sq is the initial state; 

— V = (vi,V2, ■ ■ ■ ,v z ) is a finite list of data variables (local and global); 

— T = {fx, f 2 , ■ • ■ , f w } is a finite set of functions that may change variables in 
V; 

— — >C <S x J 7 x <S is a finite set of labeled transitions, such that a state transition 

in (sj, Sj), is represented by Sj — > Sj, Vsj, Sj E S,i ^ j, G J 7 and it is 
supposed that each function is executed to completion. 

Let 7r [n . . . m] for < n < m G N be an execution path denoted by a finite 

sequence s n — V s n +i ^> • • • — V s rn with m — n transitions and m — n + 1 
states. As example, suppose we have T = {/i, /2, f3,fi, fs}', we may define the 

following execution path 7r[0..5] = s — Si — ^> S2 — ^» S3 — ^» S4 — ^» S5. 

In order to introduce timing constraints into the program, we change the 
original program V to another program V' = (S, s , V, J 7 ', — >) where: 

— V = cat(V, 7~), where cat means list concatenation in this case used to 
concatenate lists of variables; 

— T = T U A U K; 

— T = (tx, t 2 , • • ■ , tp) is a finite list of timer variables; 

— A = {ai(ife 1 ), o, 2 {tk 2 ), '■ ' i a n(ifc x ) I is a special function that asserts on 
timer variables, 1 < i < n, and t/^ G 7", 1 < d < x, 1 < fc^ < = 7~|}; 

— TZ = {^i(ii), ^2(^2), ■ • • i r p(tp) r w is a special function that resets a timer 
variable, 1 < w < p, p = and t w G T}. 

We define D : T H N as the worst-case duration of a function, such that 

(di en, if(/iSJ-) 
£>(/*), V/, G T' = I 0, if(/ 4 G A) 

[0, if(/i6ft) 
Therefore, we may express the duration D(7r[n..m]) = ^j = "x D(f ( p i ) of such 
a finite sequence 7r[n..m] representing the time elapsed from s n to s m . As exam- 
ple, suppose we have T = {h, h, h, U, h}; T = {tx,t 2 }; A = {ai(*i),aa(*i), 

03(^2)}; TZ = (£1 ) , r 2 (t 2 )}; and the execution path 7r[0..11] = sq — ^ Sx — % 

fl h «l (*l) / 5 f 2 a 2 (ti) f 4 a 3 (t 2 ) 

s 2 — > s 3 — > s 4 — > s 5 — y s 6 — > s 7 — > s 8 — > s 9 — > sxo — > Sxx, where 
ffa = rx(tx); U 2 = r 2 (t 2 l); U 3 = fx; U 4 = h; U 5 = U 6 = rx(tx); 

U ? = h\ Us = h; U 9 = a 2 (ti)', f<j> w = U\ Uu = a 3 (tx). We can conclude that 
D(tt[0..11]) - E"i D{M = D(fx) + D(f 3 ) + D{h) + D(f 2 ) + D(/ 4 ). As we 
can see, in the execution path 7r[0..11] we have three timing verifications: ai(£i), 
a 2 (tx)i and 03 (£2); and three timer resets: rx(tx), r 2 (t 2 ), and ri(ii). 



3.2 Annotation of Timing Constraints 

The inclusion of timing constraints in the source code is particularly interesting 
since it can automatically be checked as the program are being developed. To 
annotate the timing constraints in the code we use a special kind of C comment 
in such a way that this annotation does not change the code itself. In this way, 
the same annotated code can be compiled by any C compiler without breaking 
the compilation. The proposal is to have four kinds of annotations: 

— //@ DEFINE-TIMER <timer-name>. Defines a new timer variable timer-name 
which is automatically declared as an unsigned int variable. Using this an- 
notation we can add the set T to the code. 

— //@ RESET-TIMER <timer-name>. Resets the timer variable to zero. Using 
this annotation we can add the set 1Z to the code. 

- //@ ASSERT-TIMER (<logic-expr>) . Checks a user defined assert. This an- 
notation specifically is useful to check timing properties, where the assertion 
language consists in arithmetic operations with timer variables. Using this 
annotation we can add the set A to the code. 

- //© WCET-FUNCTION [<int-expr>] . Defines the WCET of the next defined 
function. Thus, we rely on a timing analyzer tool to predict worst-case timing 
bounds, for instance [3]. Using this annotation we can add the function D 
to the code. 

Figure 2(a) shows an example of code annotation from the example shown on 
Section 13.11 Even though all timer variables are incremented together, the fact 
that we have defined more than one timer implies that we may verify several tim- 
ing constraints. In the example of Figure 2, the TIMER1 is checking local timing 
constraints. Firstly, this timer verifies timing constraint related to functions /i() 
and /2()- Later, this same timer is then used to verify timing constraint over the 
functions /3O and /4O. On the other hand, the timer variable TIMER2 is used 
to verify the complete behavior of the sysem, i.e., the function calls from /i() 
up to / 5 (). 

In this paper we are just showing a coarse-grained timing constraint reso- 
lution in the level of functions. Therefore, we show only how to specifiy timing 
constraints in the source code on functions. However, as ongoing work, we are 
extending the proposed annotation method to consider fine-grained (in the level 
of instructions) timing constraints. 

3.3 Translation and Verification 

The translation consists in looking for comments that start by //@ and treat 
them appropriately. The translation of the code shown on Figure 2(a) can be 
seen in Figure 2(b). This translation is carried out automatically by a specific 
toofl. It is important to emphasize that the user has first to run the model 
checker to find conventional errors (e.g., buffer overflow, arithmetic overflow, 



4 This tool is available at 



http://esbmc.org 



//A DEFINE-TIMER TIMER1; 
//9 DEFINE-TIMER TIMER2; 

//® WCET-f miction [dl] 

void f 1 (void) . . . 

//a WCET-function [d2] 

void f 2 (void) . . 

//a WCET-function [d3] 

void f 3 (void) . . . 

//a WCET-function [d4] 

void f 4 (void) . . . 

//a WCET-function [d5] 

void f 5 (void) . . . 

int mainCint argc, char *argv[]) 
//a RESET-TIMER TIMER1=0; 
//a RESET-TIMER TIMER2=0; 
flO; f2(); 

//8 ASSERT-TIMER CTIMER1 <= alpha) ; 
//a RESET-TIMER TIMER1=0; 
f30; f40; 

//8 ASSERT-TIMER CTIMER1 <= beta) ; 



// DEFINE-TIMER TIMER1 ; 
unsigned int TIMER1; 
// DEFINE-TIMER TIMER2 ; 
unsigned int TIMER2 ; 

// WCET-function [dl] 
void fl(void) {TIMER1 
// WCET-function [d2] 
void f 2 (void) {TIMER1 
// WCET-function [d3] 
void f 3 (void) {TIMER1 
// WCET-function [d4] 
void f 4 (void) {TIMER1 
// WCET-function [dB] 
void f 5 (void) {TIMER1 



+= dl; TIMER2 += dl ; 



+= d2: TIMER2 += d2: 



+= d3: TIMER2 += d3; 



d4; TIMER2 



d5; TIMER2 += d5; 



f5(); 



ASSERT-TIMER (TIMER2 <= gamma) ; 



int mainCint argc, char *argv[]) 

// RESET-TIMER TIMER1=0; 
TIMER1 = 0; 

// RESET-TIMER TIMER2=0; 
TIMER2 = 0; 
fl(); f2()i 

// ASSERT-TIMER (TIMER1 <= alpha) ; 
assert (TIMER1 <= alpha) ; 
// RESET-TIMER TIMER1=0; 
TIMER1 = 0; 
f30; f4(); 

// ASSERT-TIMER (TIMER1 <= beta) ; 

assert (TIMER1 <= beta) ; 

f5(); 

// ASSERT-TIMER (TIMER2 <= gamma) ; 
assert (TIMER2 <= gamma) ; 



(a) 



(b) 



Fig. 2. (a) Example of Annotated C Code; and (b) Translation Result 



memory leaks, etc), and then run the model check to find for timing violations 
in the modified code. 

After translation, this new code is able to be run on ESBMC, which check 
properties using user-specified assert statement. In the proposed method the 
assert will be the way to check timing properties. In the code of Figure 2(b) we 
may see three timing verification. 

3.4 Verifying the Bridge Crossing Problem 

The bridge-crossing problem is a mathematical puzzle with real-time aspects |14j . 
Four persons, Pi to P4, have to cross a narrow bridge. It is dark, so they can 
cross only if they carry a light. Only one light is available and at most two 
persons can cross at the same time. Therefore any solution requires that, after 
two persons cross the bridge, one of them returns, bringing back the light for 
any remaining person(s). The four persons have different maximal speeds: Pi 
crosses in ti time units (t.u.), and we assume that ti < t 2 < t-s < £4. When a 
pair crosses the bridge, they move at the speed of the slowest person in the pair. 
Consider that t\ = 5; t 2 = 10; t 3 = 20; and t 4 — 25, the question is: how much 
time is required before the whole group is on the other side? Rote [14] pointed 



out that the most obvious solution is to let the fastest person (PI) accompany 
each other person over the bridge and return alone with the lamp. In this case, 
the total duration of this solution is t 2 + 1\ + t% + ti + 1± = 2ti + t 2 + 1% + t 4 = 65 
t.u. However, the obvious solution is not optimal. The correct solution in this 
case is to let P3 and P4 cross in the middle. Hence, the new total duration is 
t 2 + ti + ti + t- 2 + t 2 = h + 3t 2 + i 4 = 60 t.u. 

We implemented this problerrjfl and submitted it the ESBMC model checker. 
We first verified that 60 is indeed the optimal solution, i.e., that the elapsed 
time cannot be less than 60. The timing assertion and the ESBMC's output 
can be seen in Figure [3J We can see that the verification failed, which means 
that ESBMC find at least one execution path where the asserted condition is 
false. The ESBMC spent 3m25s to give the result. The second attempt was 
to check if the time duration could be greater or equal to 60. The result was 
SUCCESSFULL, which means that the SMT solver found that in all execution 
paths the assert condition is true. With this two results, we may conclude that 
time = 60 is indeed the optimal solution. The ESBMC spent 16m28s to give the 
result. These experiments were conducted on an Intel Pentium Dual CPU with 
4 GB of RAM running Linux OS, and ESBMC v.1.15.1 (64bits). 

//® ASSERT-TIMER (__timing__ < 60) ; 
assert C timing < 60) ; 

size of program expression: 37084 assignments 
Generated 1 VCCCs), 1 remaining after simplification 
Encoding remaining VCCCs) using bit-vector arithmetic 
Solving with SMT Solver Z3 v2.16 
Runtime decision procedure: 177.843s 
Building error trace 
Counterexample : 

Violated property: 

file bridge LT60.C line 151 function main 

assertion 

timing < 60 

VERIFICATION FAILED 

Fig. 3. Verification failed as the result of the application of the ESBMC 



4 Pulse Oximeter Case Study 

This section describes the main characteristics of the pulse oximeter and shows 
results on the application of the model checker ESBMC in the verification of 
timing constraints. All experiments were conducted on an otherwise idle Intel 
Pentium Dual CPU with 4 GB of RAM running Linux OS. We chose ESBMC 
v.l.l5.1-64bits as untimcd bounded model checker. 

5 The code, counterexample and explanation on the results may be downloaded at 
http://esbmc.org 



4.1 Problem Specification 



The pulse oximeter is responsible for measuring the oxygen saturation (SpC^) 
and heart rate (HR) in the blood system using a non-invasive method. This 
device was used as case study in [5] to raise the coverage of tests in embedded 
system combining hardware and software components. The implementation is 
relatively complex, since the final version has approximately 3500 lines of ANSI- 
C code and 80 functions. Considering that such paper does not checked timing 
constraints explicitly, and the implementation is publicly availably, we used this 
problem as a case study for our proposed method. 

The architecture consists in four components: sensor, data acquisition module 
(OEM-Ill f\, microcontroller, and LCD display. The sensor captures data on 
oxygen saturation (Sp02) and heart rate (HR) of the patient. The OEM III 
module has an interface for communication with sensor, an ASIC (Application- 
Specific Integrated Circuit) component, and a serial communication interface 
(RS-232). The ASIC component provides the values of Sp02 and HR data in 
the serial port. The microcontroller receives this data, via serial port, treat them 
and displays on the LCD. 

The packet description of the data format is shown in Table [1] A frame 
consists of 5 bytes; and a packet consists of 25 frames. Three packets (375 bytes) 
are transmitted each second. In this table, Bytel is always "01" (usually used for 
synchroization) ; Byte2 is the status byte (if sensor is not connected, for instance); 
Byte3 shows the 8-Bit Plethysmographic Pulse Amplitude; Byte4 presents HR 
and Sp02 data; and Byte5 is the checksum. 



Table 1. Packet Description 



# 


Bytel 


Byte2 


Byte3 


Byte4 


Byte5 


1 


01 


STATUS 


PLETH 


HR MSB 


CHK 


2 


01 


STATUS 


PLETH 


HR LSB 


CHK 


3 


01 


STATUS 


PLETH 


Sp02 


CHK 














25 


01 


STATUS 


PLETH 


reserved 


CHK 



In the context of timing constraints, the following functional requirements 
are considered: 

FR1. The system has to read all HR and Sp02 data in at most 1 second. In 
this case, we have to take into account the maximum frequency of the serial 
communication (9600bps), and the amount of bytes sent by the sensor device. 

6 Availabe at: |http:/ /esbmcorg] 

7 For more information refer to www.nonin.com/OEMSolutions/OEM-III-Module 



FR2. The software must check whether the frames sent by the sensor is correct, 
and show in the LCD if found any problem. This implies in verification of 
the checksum, and status bytes. Besides that, we have to show any problem 
in the LCD display. 

FR3. The user should be able to see, every second, the data of heart rate and 

oxygen saturation in the patient's blood. Therefore, we have to store patient's 

information and to show in the LCD display. 
FR4. The system must allow users to store data on HR and Sp02 in the external 

memory of the microcontroller. We have to consider the the amount of data 

and the time to store in the external memory. 



4.2 Code Annotation 

The timing constraints for this project is shown in Tabic [2j These constraints 
come from either the specification or a domain specialist. As presented before 
(see Section 13. 2p , these timing constraints are annotated into the code. It is 
worth noting that if one function calls another function, the timing constraint 
may be specified on the caller function, or on the called function, or both. 



Table 2. Timing Information 



ID 


Function 


Description 


WCET(^s) 


fl 


receiveSensorData 


receives data from the sensor 


1000 


£2 


checkStatus 


checks status 


700 


f3 


printStatusError 


displays status error 


10000 


f4 


checkSum 


calculates checksum 


2000 


£5 


printCheckSumError displays checksum error 


10000 


Hi 


storeHRMSB 


stores HR data 


200 


fT 


storeHRLSB 


stores HR data 


200 


f8 


storeSp02 


stores Sp02 data 


200 


f9 


averageHR 


calculates average of HR data 


800 


flO 


averageSp02 


calculates average of Sp02 data 


800 


fll 


getHR 


returns the stored HR value 


200 


fl2 


getSp02 


returns the stored Sp02 value 


200 


fl3 


printHR 


displays HR on the LCD 


5000 


fl4 


printSp02 


displays Sp02 on the LCD 


5000 


f!5 


insertLog 


inserts HR/Sp02 in RAM microcontroller 


500 



4.3 Verification Results 



The pulse oximeter code is part of a real implementation. The code adopted, 
and the verification results are publicly available at: http: / / esbmc.org| In or- 



der to verify the timing constraints using ESBMC, we had to isolate hardware- 
dependent code. With this aim we used #if , #else, and #endif preprocessor 
directives. This experiment verifies if in all execution paths the timing constraints 
are met when implementing the four functional requirements (FR\, FR2, FR3, 
and FR4). This program behavior is explained as follows: The specification con- 
siders that we should read three packets of data per second. Each packet has 
twenty five frames. Each frame has five bytes. In this way we have to: 

1. read data bytes calling function fa (receiveSensorData); 

2. for each byte read: 

(a) to check status of the second byte of each frame by calling function fa 
(checkStatus); if there is an error, it should be called the function fa 
(printStatusError); 

(b) to check the fifth byte of each frame by calling function fa (checksum); if 
there is an error, it should be called the function fa (printCheckSumError); 

(c) to read the fourth byte of first frame and to call function fa (storeHRMSB); 

(d) to read the fourth byte of second frame and to call function fa (storeHRLSB); 

(e) to read the fourth byte of third frame and to call function fa (storeSp02); 

3. call the functions fa (average_HR), fao (average_SpD2), fa\ (getHR), /12 
(getSp02), /13 (printHR) with HR value as argument, /14 (printSp02) with 
Sp02 value as argument, /15 (inscrtLog) with HR value as argument, and 
/15 (insertLog) with Sp02 value as argument. 



Table 3. Experimental Results 



ID 


% Checksum Error 


Time(s) 


Result 


1 


0% 


28.9 


successful 


2 


16.6% 


20.3 


successful 


3 


20% 


20.2 


successful 


4 


25% 


19.9 


successful 


5 


33.3% 


19.9 


successful 


6 


50% 


21.1 


failed 


7 


100% 


30.2 


failed 



Figure 2] depicts part of the pulse oximeter code submitted to the ESBMC. 
Table |3] shows the experimentl results. We experimented seven scenarios taking 
into account the percentage of checksum errors. The percentage considered was 
0%, 16.6%, 20%, 25%, 33.3%, 50%, and 100%. Excepting the best scenario (0%) 



//'DEFINE-TIMER TIMER; 
unsigned int TIMER; 

Ilk WCET-FUNCTION [5000] 

void printHR (unsigned int line, unsigned int valueHR) 
{ 

TIMER += 5000; 

char sHR[16] ; 

sprintf(sHR, "HR:'/.d\a", valueHR); 
printLCD(sHR, line, 1); 

} 

int main (void) { 

//'RESET-TIMER TIMER; 
TIMER=0 ; 

' for (k=0; k<3; k++) { 

for (j=0; j<25; j++) { 
for (i=0; i<5; i++) { 

Byte[i] = receiveSensorDataO ; 

if ((i==l) kk (checkStatus(Byte[i]))) 

printStatusError (LINED ; 
if ((i==4) kk (checkSum(Byte))) 

printCheckSumError(LINE2) ; 
if (i==3) { 

if (j==0) storeHRMSB (Byte[i], k) ; 
if (j==l) storeHRLSB (Byte[i], k) ; 
if (j==2) storeSp02 (Byte[i], k) ; 

} 

> 

} 

} 

averageHRO ; 
averageSp02() ; 
HR = getHRO ; 
Sp02 = getSp02() ; 
printHR(LINEl, HR) ; 
printSp02(LINE2, Sp02) ; 
insertLog(HR) ; 
insertLog(Sp02) ; 

// ASSERT-TIMER (TIMER < 1000000) // one second; 
assert (TIMER < 1000000) ; 

} 

Fig. 4. Code for running in the ESBMC model-checker 



and worst scenario (100%), all timing performance was 20s in average. As pre- 
sented in Table[3J if considered the worst-case scenario, in this case 100% of data 
error, timing constraints arc not met. However, if it is considered that it is not 
practical to consider an extreme situation like this one, we may conclude that 
up to 33.3% of checksum errors, the system will continue to reach the timing 
constraints. 



5 Related Work 



Lamport [TU] advocates that most real-time specifications can be verified using 
existing languages and methods. He proposed to represent time as an ordinary 
variable (now), which is incremented by an action (Tick), and express timing 
requirements with a special timer variable in such a way that such specifications 
can be verified with an conventional model checker. He call this method as 
model checking explicit-time specifications. He proposes to specify the system 
and timing constraints using TLA+ (Temporal Logic of Actions), which is a 
high-level mathematical language. The problem is that the learning curve of the 
TLA+ may be high. 

Ostroff and Hg [T3] presented a framework that allows specification, devel- 
opment and verification of discrete real-time properties of reactive systems. This 
framework considers a Timed Transition Model (TTM) as underlying compu- 
tational model, and Real-Time Temporal Logic (RTTL) as the requirements 
specification language. The authors provide a conversion procedure for mapping 
the model and specification into a finite state fair transition systems, which may 
be input to a (untimed) tool, in this case STeP model-checker [2J, for state ex- 
ploration for checking real-time systems properties. One problem of this method 
is that the converted clocked formulas count the number of tick events that oc- 
cur. Thus, the size of the formulas grow according to the bounds that must be 
checked. Since the cost of checking a linear time formula is exponential in the 
size of the formula, these procedures are only useful for small bounds. 

Chun and Hung [4] propose a new class of Duration Calculus (DC) called 
DC< ly whose formulas correspond to expressions over the set of state occurrence 
for one time unit (or less), and using conventional variables to implement relative 
time. They model the real-time system using DC and convert its components 
into DC<! specifications. Each DC^ t specifications is translated to an automata 
model. In this way, the whole system is modeled by the synchronisation of several 
automatas. Later, the resulting automata is translated to the SPIN untimed 
model checking language (in this case Promela). They applied their method 
in the Biphase Mark Protocol. However, they do not show how translate from 
automata model to Promela language. Additionaly, it is not clear what timing 
constraint was verified in this case study. 

Canty and Majumdar [7] show that checking safety properties for real-time 
event-driven programs is undecidable. The undecidability proof for the safety 
checking problem uses an encoding of the execution of a 2-counter machine as a 
real-time event-driven program. The result is undecidable because such programs 
are not finite-state. In this case, the task buffer as well as the call stack can grow 
unboundedly large in the course of the execution. They suggest to use higher- 
level languages, such as Giotto, which statically restricts the ability to post tasks 
arbitrarily, these higher-level languages ensure that for any program, at any point 
of the execution, there is at most a bounded, statically determined, number of 
pending calls. In this case, just by finiteness of the state space, all verification 
problems are dccidablc. 



The input of the related work analyzed are: Temporal Logic of Actions 
(TLA) specifications, Timed Transition Model + Real-Time Temporal Logic 
(TTM/RTTL), Duration Calculus (DC), and Giotto programs. To the best of 
our present knowledge, there is no work that verify timing constraints using C 
code as input language. 

6 Conclusions and Future Work 

Model checking is often used for finding errors rather than for proving that they 
do not exist. However, model checkers are capable of finding errors that are 
not likely to be found by simulation or test. The reason for this is that unlike 
simulators/testers, which examine a relatively small set of test cases, model 
checkers consider all possible behaviors of the system. 

This paper described how to use an untimcd software model checker to verify 
timing constraints in C program language. In our proposed method we use the 
C language because it is one of the most commom implementation language of 
embedded systems. As far as we are aware, there are only few approaches that 
deal with model-checking timing constraints using C code as input language. We 
specified the timing behavior using an explicit-time code annotation technique 
for verifying timing properties using ordinary model checkers. The main advan- 
tage of an explicit-time approach is the ability to use languages and tools not 
specially designed for real-time model checking. As pointed out by Lamport [10] 
"the results reported that verifying explicit-time specifications with an ordinary 
model checker is not very much worse than using a real-time model checker" . 

Experimental results have shown that the proposed method is promissing, 
mainly because now it is possible to verify timing constraints in the C code. 
Therefore, we are just following a movement toward application of formal verifi- 
cation techniques to the implementation level. In this case, we avoid construct- 
ing models explicitly and go directly to code verification. As presented before, 
this method is particularly interesting when taking into account legacy code. 
However, we argue that our proposed method is not an alternative to methods 
currently available in the literature, but complementary. We also show that using 
our proposed method it is possible to investigate several scenarios. 

This paper just considered single-threaded code. It is an ongoing work to 
consider multi-threaded code, which is also supported by ESBMC. Therefore, 
we need to consider interleavings and priorities. 

This work proposed just a coarse-grained timing constraint resolution, in this 
case, we considered just timing constraints in functions. Thus, one future work 
is to extend both the code annotation method and the timing verification to 
consider fine-grained timing constraints, maybe in critical sections, for instance 
to add timing duration between two instructions representing a sequential block, 
and timing bounds for loops. 
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